Skip to content

fix: support EKS member impersonation#339

Open
vgocoder wants to merge 1 commit into
1Panel-dev:masterfrom
vgocoder:fix/eks-member-impersonation
Open

fix: support EKS member impersonation#339
vgocoder wants to merge 1 commit into
1Panel-dev:masterfrom
vgocoder:fix/eks-member-impersonation

Conversation

@vgocoder

Copy link
Copy Markdown

Summary

  • Avoid client-certificate CSR waits for imported token/exec kubeconfigs that can authenticate with the original credential and impersonate members instead.
  • Preserve certificate-based member auth where CSR signing is available, while falling back to impersonation when a member binding has no certificate.
  • Reuse the same impersonation-aware access setup across cluster access, proxy, and webkubectl config generation.

Why

Some managed Kubernetes services, including EKS, accept and approve kubernetes.io/kube-apiserver-client CSRs but do not populate status.certificate. KubePi currently waits for the certificate and returns a 500 after the CSR timeout when creating a cluster member.

Test Plan

  • go test ./internal/api/v1/cluster ./internal/service/v1/clusteraccess ./internal/api/v1/proxy ./internal/api/v1/webkubectl

Manual Verification

  • Reproduced on an EKS cluster: CSR became Approved with empty status.certificate.
  • Verified patched KubePi creates an EKS cluster member in ~1s and the generated EKS RBAC allows the impersonated user to list namespaces.

@wanghe-fit2cloud

wanghe-fit2cloud commented Jul 6, 2026

Copy link
Copy Markdown
Member

@vgocoder

Thanks for the contribution. The overall direction of this PR makes sense, and it can address the issue where member creation times out when some clusters, such as EKS, approve the CSR but do not return a certificate.

However, the current implementation reuses the server-side impersonation configuration for the webkubectl kubeconfig download flow. Since webkubectl sends the generated kubeconfig to the member terminal, if that kubeconfig contains the original token or exec credentials used to import the cluster, a member could remove the impersonation fields and bypass KubePi's member RBAC restrictions.

I recommend separating the handling of server-side internal access from the webkubectl downloadable kubeconfig flow, and ensuring that original cluster credentials are not exposed to members before merging this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants